1. Field of the Invention
The present invention relates generally to network communications, such as over the Internet/World-Wide-Web and more particularly, to a system and method for reducing communication bandwidth and overheads for entities providing and consuming Web-based services (WS).
2. Description of the Prior Art
Web Services (WS) is a programming model comprising a set of standards developed to provide programmatic access to application logic on a remote machine. This application logic is accessible to clients on every platform, and in every programming language. One of the core Web Services' building blocks is SOAP (Simple Object Access Protocol), a standard framework that allows, but it is not limited to, RPC (Remote Procedure Call) messages to be transmitted as XML documents and invokes the capabilities of Web Services. It is known that WS are used extensively not only over the Internet (or Web) but also on enterprise networks, even between machine located in the same site or even room. While WS were initially designed for access across the web, WS are popular inside Intranets, i.e., enterprise networks.
FIG. 1A depicts a typical WS architecture 10 including its logical components. As shown in FIG. 1A, a Web service provider 18 is responsible for deploying Web services and publishes them with a Web service broker 15 that is responsible for service registration and discovery of Web services. Particularly, the broker lists various service types, descriptions, and locations of services that help the service requesters find and subscribe to the required services. A Web service requestor 12 is responsible for the service invocation by locating the Web service using the service broker 15, invokes the required services, and executes it from the service provider. More particularly, as described in the book “Developing Java™ Web Services” (Ramesh Nagappan, et al., Wiley Publishing, Inc. 2003), the Web service provider 18 includes a services container 28 that acts as the Web services runtime environment and hosts the service provider. The services container 28 particularly defines the environment meant for client communication implementing a standardized way to describe the network services using a standard XML schema-based specification for describing web services known as Web Services Definition Language (WSDL), and facilitates web service deployment and administration. In addition, it handles the registration of the service description with the service registries 30a,b. Such registries include those implementing a Universal Description, Discovery and Integration (UDDI) standard 30a (www.UDDI.org) or an ebXML registry 30b that defines registry services, interaction protocols, and message definitions, and further acts as a storage for shared information (www.ebXML.org). The web service requester 12 includes a services delivery component 22 that acts as the client runtime environment by looking up the services registries to find the required services and invoke them from the service provider using SOAP messaging 25. As known, the SOAP protocol includes the following elements: a SOAP envelope that serves as a container for other elements of the SOAP message; a SOAP transport binding for the underlying transport protocol; a set of SOAP encoding rules for representing data in a message (maps instances of application-specific data types to XML messages); and an application interaction pattern, most often a RPC convention, which is defining the representation for RPC requests and responses and is defined as a way of serializing remote procedure calls and responses as SOAP messages.
FIG. 1B, depicts an exemplary client-server interaction in a conventional SOAP RPC implementation. As shown in FIG. 1B, a client 12 interacts with a service provider (or simply “service”) 18 over a network 99 such as the Internet, using a SOAP/HTTP protocol (i.e., a SOAP message protocol using an HTTP transport binding). The SOAP messaging protocol enables messages 25 to be exchanged between the service provider endpoint 18 and the service requestor endpoint 12 in request-response pairs. This is the method SOAP uses with the HTTP (Internet) message transport and/or the RPC convention. While SOAP defines how messages should be exchanged over HTTP, it is understood that any communications protocol (e.g., SMTP, MQSeries, Raw Sockets, etc) or method can be substituted for HTTP. In this conventional implementation, client 12 makes remote procedure calls (RPCs) on service provider 18 by sending one message for each call. In a similar manner, service provider 18 responds to these calls by sending one message back to client 12 for each response. The main technique in Web Services is respective processes of composing a SOAP message before sending it and deciphering a SOAP message after receiving it. These processes for a SOAP message are generally performed by creating DOM (Document Object Model), or similar tree-like, objects in memory. In this manner, processes can be performed using the tree representation of the SOAP message without considering the textual representation of the message.
Due to the ASCII nature of XML, implementation of Web Services incorporates significant bandwidth requirements and communication overheads. In addition, WS are self-describing, such that a client and server need only to recognize the format and content of request and response messages. The definition of the WS message format travels with the message; no external metadata repositories or code generation tools are required. Thus, the overheads are obvious when analyzing the content of any SOAP message. Using SOAP and XML not only translates into very large messages, i.e., significant overheads in the TCP/IP stack and increased bandwidth usage, but also in significant parsing overheads, due to the rich structure of SOAP. Furthermore, HTTP, which is WS's most commonly used transport, adds additional communication and parsing overheads.
On the traditional desktop/server platforms, the impact of these overheads has been largely offset by using Gigabit Ethernet networks, faster CPUs and more memory, and by eliminating the performance bottlenecks present in the initial SOAP implementations, such as the Apache Axis engine. Unfortunately, resource-constrained mobile platforms, such as cell phones, PDAs, or laptops, cannot benefit from these solutions. Hardware-oriented approaches don't typically apply to these energy- and size-constrained devices, as faster networks or CPUs, or more memory, consume more power and don't always fit in the desired form factors. Similarly, SOAP engine implementations require additional optimizations to reduce their memory footprints.
In a typical B2B web services deployment scenario, for example, a web service client may make several calls to the service end point, and these calls may have several parameters that do not change from invocation to invocation. Consider for instance several buyers interacting with a seller's web service end point by using web service calls to send purchase orders to the seller. Each purchase order may have several fields, and many of these fields may describe the buyer and will therefore be the same for a particular buyer for each invocation. This type of parameter repetition is mainly due to the stateless nature of web services. Keeping state specific to the combination of (service end-point, client) can enable a better compression ratio of the network traffic than feasible with simple stateless gzip style compression.
A variety of techniques that facilitate the WS services and particularly, message compression, are known in the art. Such techniques include, for example:    1) Hartmut Liefke and Dan Suciu's “XMill: an Efficient Compressor for XML Data” (ACM SIGMOD 2000) describing a tool for compressing XML data, which achieves about twice the compression ratio of gzip at roughly the same speed. XMill separates structure from data, groups related data items, and applies a collection of specialized compressors. Can only be applied after the WS message is generated, which increases message latencies.    2) WAP Binary XML (WBXML) (http://www.w3.org/TR/wbxml/) June 1999, describes splitting XML into predefined tokens, that are binary encoded, and rest, which is encoded inline. Token tables are kept at both send/receive sides. Initially, only token tables for WAP were available; additional tables for SyncML and DRMREL (Digital Rights Management Rights Expression Language) were defined later. Major benefit is that a WBXML-aware SAX parser has very low overhead. Major drawback is that it can only be used for a predefined XML dialect, as token tables for the XML dialect must exist on both ends.    3) Marc Girardot and Neel Sundaresan's. “Millau: an encoding format for efficient representation and exchange of XML over the Web”, (http://www9.org) May 2000, describes separation of structure from text for compression and takes advantage of associated schema. Extension to WBXML as it compresses the inline text and understands XML basic types. Millau has the same drawbacks as WBXML.    4) Christian Werner, Carsten Buschmann, Stefan Fischer's “Compressing SOAP Messages by using Differential Encoding” (IEEE International Conference on Web Services, July 2004), describes in a first part of the paper comparing bandwidth requirements of SOAP (.NET and Java), RMI-IIOP, Corba, RMI, and gziped SOAP. Second part describes Differential SOAP compression, which sends only the difference between a message and a previous one. In practice, differential encoding works by first computing a collection of skeleton messages by using the WSDL file; next, it computes the difference between a message and a predicted skeleton, which then gets transmitted. In differential encoding, coding and decoding overheads can be significant.    5) M. Tian, T. Voigt, T. Naumowicz, H. Ritter, J. and Schiller's “Performance Considerations for Mobile Web Services” (Elsevier Computer Communications Journal, Volume 27, Issue 11, 1 Jul. 2004, Pages 1097-1105) describes how compression is not always beneficial, especially when it overloads the server.    6) Kenneth Barr and Krste Asanovic's “Energy Aware Lossless Data Compression” (Mobisys 2003, May 2003) describes how with typical compression tools, it takes more energy to compress and send data than sending the uncompressed data. Hardware-aware optimizations of compression tools are shown that reduce the energy used for compression. This paper shows that the compression scheme must be selected carefully.    7) Naresh Apte, Keith Deutsch, and Ravi Jain's “Wireless SOAP: Optimizations for Mobile Wireless Web Services” (poster at www2005.org, May 2005) proposes two optimization techniques: 1) Name Space Equivalency (NPE), and 2) WSDL Aware Encoding (WAE). NPE allows recovery of XML message in a different but equivalent form. WAE requires a mobile device gateway, which creates coding tables for the operations described in the WSDL file. NPE does not appear to deliver significant compression while WAE requires a gateway.    8) Toshiro Takase, Hisashi Miyashita, Toyotaro Suzumura, and Michiaki Tatsubori's “An Adaptive, Fast, and safe XML Parser Based on Byte Sequences Memorization” (www2005.org, May 2005) describes an XML parser (“Deltarser”) that uses history to identify previously seen syntactic constructs and reuses the results of the matching constructs. The Deltarser parser reduces parsing overheads on the receiver node but it does not reduce bandwidth requirements nor the overheads of generating the message on the sending node.
It would be highly desirable to provide a system and method that provides one or more optimizations for significantly reducing SOAP messaging processing overheads in deployed Web Services environments.
It would be highly desirable to provide a system and method that provides one or more optimizations for significantly reducing SOAP messaging communication overheads in deployed Web Services environments.
It would be highly desirable to provide a system and method that provides a WS/SOAP messaging compression optimization scheme that provides comparable compression with significantly lower energy and latency costs than existing WS/SOAP messaging compression schemes.